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
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.

63
Avatar de l'auteur

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Le poing Dev – Round 8

Un grand huit émotionnel

22:05 Next 7
Guacamole sur un plateau

Guacamole sur un plateau (1/5) : on monte un bastion sécurisé

Vous cherchez le bastion ?

17:13 WebSécu 7
Mur d’OVHcloud à Roubaix, avec le logo OVHcloud

Projet européen sur le cloud : OVHcloud s’est retirée au dernier moment et s’explique

Tu me vois, tu ne me vois plus

16:45 IAWeb 3

Sommaire de l'article

Introduction

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

Deux autres failles apparaissent déjà

Le poing Dev – Round 8

Next 7
Guacamole sur un plateau

Guacamole sur un plateau (1/5) : on monte un bastion sécurisé

WebSécu 7
Mur d’OVHcloud à Roubaix, avec le logo OVHcloud

Projet européen sur le cloud : OVHcloud s’est retirée au dernier moment et s’explique

IAWeb 3
IA Act

AI Act européen : un compromis de haute lutte, de rares interdictions

DroitIA 1
Panneau stop

Apple bloque Beeper, qui permettait d’utiliser iMessage sur Android

WebSoft 15

#LeBrief : faux avis sur Internet, enquêtes sur l’accord Microsoft et OpenAI, cybersécurité aux États-Unis

Un mélange entre une réunion d’Anonymous et de tête d’ampoules, pour le meilleur et le pire

652e édition des LIDD : Liens Intelligents Du Dimanche

Next 9
dessin de Flock

#Flock distribue des mandales tous azimuts

Flock 14
Un Sébastien transformé en lapin par Flock pour imiter le Quoi de neuf Docteur des Looney Tunes

Quoi de neuf à la rédac’ #11 et résumé de la semaine

Next 43
Carte graphique AMD GeForce

Cartes graphiques : 30 ans d’évolution des GPU

Hard 29

Google lance son opération de communications Gemini pour rivaliser avec OpenAI

IA 6
Ecran bleu de Windows

Linux : le composant systemd se dote d’un écran bleu de la mort

Soft 41
Une petite fille en train d'apprendre à programmer et hacker logiciels et appareils électroniques

Un roman graphique explique les logiciels libres aux enfants

SoftSociété 21
Nouveautés pour Messenger

Meta lance (enfin) le chiffrement de bout en bout de Messenger, entre autres

Socials 6

#LeBrief : cloud européen, OSIRIS-REx a frôlée la catastrophe, CPU AMD Ryzen 8040

Windows en 2024 : beaucoup d’IA, mais pas forcément un « 12 »

Soft 21
Einstein avec des qubits en arrière plan

Informatique quantique, qubits : avez-vous les bases ?

HardScience 9
Notifications iPhone

Surveillance des notifications : un sénateur américain demande la fin du secret

DroitSécu 18

En ligne, les promos foireuses restent d’actualité

DroitWeb 19

#LeBrief : modalité des amendes RGPD, cyberattaque agricole, hallucinations d’Amazon Q, 25 ans d’ISS

Logo Twitch

Citant des « coûts prohibitifs », Twitch quitte la Corée du Sud

ÉcoWeb 31
Formation aux cryptomonnaies par Binance à Pôle Emploi

Binance fait son marketing pendant des formations sur la blockchain destinées aux chômeurs

Éco 10
Consommation électrique du CERN

L’empreinte écologique CERN en 2022 : 1 215 GWh, 184 173 teqCO₂, 3 234 Ml…

Science 8
station électrique pour voitures

Voitures électriques : dans la jungle, terrible jungle, des bornes de recharge publiques

Société 78

#LeBrief : intelligence artificielle à tous les étages, fichier biométrique EURODAC

KDE Plasma 6

KDE Plasma 6 a sa première bêta, le tour des nouveautés

Soft 13
Un homme noir regarde la caméra. Sur son visage, des traits blancs suggèrent un traitement algorithmique.

AI Act et reconnaissance faciale : la France interpelée par 45 eurodéputés

DroitSociété 4
Api

La CNIL préconise l’utilisation des API pour le partage de données personnelles entre organismes

SécuSociété 3
Fouet de l’Arcep avec de la fibre

Orange sanctionnée sur la fibre : l’argumentaire de l’opérateur démonté par l’Arcep

DroitWeb 26
Bombes

Israël – Hamas : comment l’IA intensifie les attaques contre Gaza

IA 22

#LeBrief : bande-annonce GTA VI, guerre électronique, Spotify licencie massivement

Acheter sur Internet et payer avec sa carte bancaire

La DGCCRF traque les faux avis sur Internet avec son Polygraphe

ÉcoWeb 16

Logo OpenAI

Au Royaume-Uni et aux États-Unis, l’accord entre Microsoft et OpenAI à la loupe

Droit 4

Une main tenant de gros paquets de dollars

87 % des agences états-uniennes ne parviennent pas à respecter les normes de cybersécurité

DroitSécu 3

Florie Marie démissionne de la présidence du Parti Pirate International

Société 8

Commentaires (63)


loloemr
Le 30/09/2014 à 08h29

#1

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

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


anonyme_92fcfbdd6cc3f0397af3a985adab6b1b
Le 30/09/2014 à 08h31

#2

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


JCDentonMale
Le 30/09/2014 à 08h33

#3

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


Khalev
Le 30/09/2014 à 08h36

#4






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=" /> ?



LordZurp Abonné
Le 30/09/2014 à 08h56

#5

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 …


Naunaud
Le 30/09/2014 à 09h02

#6






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)



cendrev3
Le 30/09/2014 à 09h11

#7






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.



Jed08
Le 30/09/2014 à 09h15

#8


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.


loloemr
Le 30/09/2014 à 09h24

#9






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=" />



Debcool
Le 30/09/2014 à 09h46

#10






JCDentonMale a écrit :

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


+1

Ou encore zsh, csh…



sylvere
Le 30/09/2014 à 09h52

#11






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)



Jed08
Le 30/09/2014 à 09h52

#12






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.”



levhieu
Le 30/09/2014 à 09h55

#13






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.



sylvere
Le 30/09/2014 à 09h59

#14






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



Glyphe
Le 30/09/2014 à 10h13

#15

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.


cendrev3
Le 30/09/2014 à 10h56

#16






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 :






HarmattanBlow
Le 30/09/2014 à 11h20

#17






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.



tazvld Abonné
Le 30/09/2014 à 11h35

#18






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!



Zyami Abonné
Le 30/09/2014 à 11h47

#19






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.



Winderly Abonné
Le 30/09/2014 à 12h02

#20






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=" />



Skruybutt
Le 30/09/2014 à 12h16

#21

Hello,

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


Zyami Abonné
Le 30/09/2014 à 12h21

#22






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.



atomusk
Le 30/09/2014 à 12h21

#23






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=" />



anonyme_f168d692f50618cb9f3fd8cadce4e6bc
Le 30/09/2014 à 12h49

#24

Maintenant remplacez Bash par Systemd et admirez le carnage


athlon64
Le 30/09/2014 à 12h53

#25






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=" />



Aphelion
Le 30/09/2014 à 12h54

#26






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.



Glyphe
Le 30/09/2014 à 13h22

#27






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.



Zyami Abonné
Le 30/09/2014 à 13h27

#28






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.



yl
Le 30/09/2014 à 13h28

#29






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.



HarmattanBlow
Le 30/09/2014 à 14h03

#30






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.



yl
Le 30/09/2014 à 14h20

#31






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.



Skruybutt
Le 30/09/2014 à 14h24

#32






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=" />



Skruybutt
Le 30/09/2014 à 14h24

#33






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=" />



lateo
Le 30/09/2014 à 14h47

#34






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.



HarmattanBlow
Le 30/09/2014 à 14h50

#35






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.



athlon64
Le 30/09/2014 à 14h53

#36






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



lateo
Le 30/09/2014 à 14h59

#37






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=" />



athlon64
Le 30/09/2014 à 15h04

#38






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=" />



lateo
Le 30/09/2014 à 15h19

#39






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.



athlon64
Le 30/09/2014 à 15h27

#40






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=" />



guildem Abonné
Le 30/09/2014 à 15h34

#41






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=" />



athlon64
Le 30/09/2014 à 17h04

#42






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



guildem Abonné
Le 30/09/2014 à 17h46

#43






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.



athlon64
Le 30/09/2014 à 17h56

#44






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é



guildem Abonné
Le 30/09/2014 à 18h12

#45






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.



GutsBlack
Le 30/09/2014 à 21h31

#46






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.



flamwolf
Le 01/10/2014 à 06h58

#47


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 …


guildem Abonné
Le 01/10/2014 à 07h05

#48






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…



athlon64
Le 01/10/2014 à 07h23

#49






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



guildem Abonné
Le 01/10/2014 à 08h54

#50






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)



Zulgrib Abonné
Le 01/10/2014 à 09h00

#51

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


athlon64
Le 01/10/2014 à 09h01

#52






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=" />



guildem Abonné
Le 01/10/2014 à 09h03

#53






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



guildem Abonné
Le 01/10/2014 à 09h06

#54






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 :)



Zulgrib Abonné
Le 01/10/2014 à 09h12

#55






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.



athlon64
Le 01/10/2014 à 09h24

#56






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=" />



ungars
Le 01/10/2014 à 11h27

#57

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…


Khalev
Le 01/10/2014 à 13h23

#58






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.