faille NTP sur Lion : quels risques ?

Sur Yosemite 10.10.1, le patch semble ne pas avoir corrigé 4 et 7. Ce qui est assez étrange.

Il y a plusieurs manières de procéder pour patcher complètement le shell :
a) la plus longue est de prendre les sources du système, y appliquer tous les patchs disponibles, de recompiler et de remplacer l'existant par cette nouvelle version.
L'intérêt est de bien conserver la même version de bash, patchée, donc de limiter les risques.
b) la plus courte consiste à prendre la dernière version de bash, avec tous ses patchs, et de la compiler puis de l'installer.
Là, c'est rapide et facile à faire mais on passe de 3.2.x à 4.3.y et il y a toujours des risques de compatibilité potentiels.

Si tu veux faire vite et ne pas te prendre la tête, tu peux suivre les recommandations du site Shellshocker.net et récupérer bash avec brew.

Au boulot, j'ai préféré la solution un peu plus compliquée consistant à patcher l'exacte version en cours sur Snow Leopard. Mais je suis un peu formaliste...
 
J'ai récupéré bash avec brew et tout retesté : cette fois-ci les failles 4,5 et 7 semblent avoir été corrigées sur ma machine. Je n'ai qu'un seul doute concernant la 4.

Pour la ligne de code 4 que voici :

bash -c 'true <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF' || echo "CVE-2014-7186 vulnerable, redir_stack"
….

il est dit :
A vulnerable system will echo the text "CVE-2014-7186 vulnerable, redir_stack"
.
Or, voici ce que j'obtiens :

bash: avertissement :« here-document » à la ligne 0 délimité par la fin du fichier (au lieu de « EOF »)
….cela étant répété une quinzaine de fois.

Est-ce bon ou non ?

Edit : si la faille Shellshock n'est pas entièrement corrigée sur Yosemite 10.10.1, il faudrait faire remonter à Apple, non ?
 
Pour la question : c'est bon [bash se plaint de ce que la limite attendue (EOF) n'est pas présente ; et comme il y a quatorze limites et qu'aucune n'est présente il se plaint quatorze fois !]

Pour la remarque : à mon avis ils le savent très bien et ils s'en contrefichent...
 
Bon, en ce qui me concerne je pense donc que tout est o.k et je te remercie sincèrement pour ton aide. :up:

Maintenant, concernant Yosemite, « s'ils le savent et qu'ils s'en contrefichent » comme tu dis, c'est quand même pas très sérieux de leur part. Il faudrait quand même avertir les utilisateurs, non ? Moi, sur Snow Leopard, j'aurais cette faille mieux corrigée qu'un utilisateur de Yosemite !!???

De toute façon, question sécurité chez Apple, je les trouve un peu légers.

En 2010/2011, j'ai été en triple boot Snow Leopard (du temps où il était donc encore suivi question sécurité)/ Seven/ Linux Ubuntu et j'étais toujours étonné du tout petit nombre de mises à jour de sécurité que j'avais sur ma partition Mac OS X par rapport à celles que j'installais assez régulièrement sur ma partition Linux, système pourtant peu utilisé en général.
 
C'est le côté intriguant de la gestion de la sécurité sur OS X. En fait, Apple, en dépit de ses richesses (il y a quand même pas mal de milliards de doublezons en stock, donc de capacité à produire du logiciel et à l'entretenir), ne consacre que le strict minimum à la sécurité et ne répare que certaines failles [car les autres logiciels open source présents sur OS X ne sont mis à jour que sporadiquement, eux-aussi].

Je pense qu'ils ne raisonnent qu'en terme de risque : la vraie faille Shellshock importante à leurs yeux est la capacité à passer des ordres douteux via un site Web contenant des scripts CGI écrits en bash, par le biais de variables d'environnements. Ils n'ont donc appliqué que les patchs correspondants à ce problème.
Moins de patch = moins de tests à faire => moins de bugs éventuellement ajoutés.

C'est un calcul à la petite semaine mais pour l'instant ils s'en sortent très bien comme ça...
 
Une petite question, bompi : pourquoi s'amuser à télécharger les sources sur le site d'Apple alors qu'un `sudo port install ntp`fait ça correctement&#8230; et plus simplement (soit, il faut avoir Xcode, d'installé, mais il y a un installeur pour ça)

j'ai rien dit, ça s'installe mais ça ne fonctionne plus après&#8230;
en fait c'est bon, fallait juste modifier le chemin de ntpd dans /usr/libexec/ntpd-wrapper et le changer par /opt/local/sbin/ntpd

le seul truc, c'est que si je coupe ntpd par les préférences systèmes, j'ai:
Bloc de code:
29/12/14 12:45:07	ntpd[448]	mlockall(): Function not implemented

(le process est quand même terminé)

Sinon, j'ai l'impression qu'il va valoir que je revois les règles :

Bloc de code:
29/12/14 12:45:13	org.ntp.ntpd[455]	restrict default: KOD does nothing without LIMITED.
29/12/14 12:45:13	ntpd[455]	restrict ::: KOD does nothing without LIMITED.
 
Dernière édition:
Pourquoi ?

a) déjà, comme je l'indiquais un peu avant, pour limiter les problèmes d'incompatibilité potentiels, je trouve préférable de repartir des sources d'Apple. En effet, il y a parfois un décalage très important entre la version que Apple décide d'inclure dans son système et celle en cours dans les autres.
Ainsi bash est en 3.2.x alors que sur Linux, ce sera plutôt une version 4.3.y : certains scripts de base pourraient ne plus fonctionner correctement et, pour avoir voulu combler une faille on se retrouverait avec un système défaillant [sh est lancé au démarrage et est en fait bash, contrairement à d'autres UNIX].
Pour ntp, c'est moins gênant... pour les systèmes pour lesquels Apple propose un patch (la version est récente). Mais pour Snow Leopard c'est à vérifier.
Enfin, il arrive qu'Apple corrige légèrement les sources (en C) de ces programmes pour redéfinir telle constante ou macro. À repartir de la version standard, on peut louper ces ajustements.

b) comme ton exemple le montre, avec MacPort, Fink ou les sources à la main, on installe les programmes dans des endroits qui ne sont pas au coeur du système (/opt, /sw, /usr/local) et je ne trouve pas ça très bon en général. C'est sans doute lié à mes années de bidouilles sur Linux et d'autres UNIX où, mode mono-utilisateur, je me retrouvais parfois sans la moitié de mes utilitaires, qui montaient sur une autre partition... qui n'était pas montée.

c) au a) et au b) j'ajoute que, donnant ici des conseils à des utilisateurs qui, en général, ne saisissent pas tous les éléments en jeu, il faut faire au plus sûr. Et recompiler les sources d'Apple avec les compilateurs d'Apple reste le plus sûr (en terme sûreté de fonctionnement, pas de sécurité).

d) personnellement, ça fait des années que j'utilise certains programmes (bash, ruby, perl, divers services) au lieu de ceux du système, mais si ça casse ce n'est pas gênant... ;) Ça m'embêterait de mettre quelqu'un dans la panade, à vouloir lui donner un coup de main.
 
Bompi , en plus d'être hyper efficace sur les questions de sécurité, tu cadres assez bien la question de l'adaptation des réponses au supposé " niveau" de l'utilisateur. :up:
Comme je ne suis pas coutumier des flatteries, c'est à prendre cash ( comme disent les jeunes ) .
Je ne suis pas forcément sur que les sources apple le soient davantage ( sures ) .
J'ai utilisé pou ma part le script proposé plus haut ( sous SL ) , qui change carrément la version de NTP .
Je suis interrogatif sur la question yosemite et la suite pour NTP .
Ayant utilisé des machines sous UNIX, je retrouve là des "ways of programming" au sens de Knuth . Ce qui ne veut pas dire que j'aille plus loin que cela:D.

Quand je regarde et compare les questions de sécurité sur Apple et eOS ( les joies du double boot ), pas sur que la vitesse et le sérieux soient du coté prévu .. mais j'ai de la chance aussi parfois :love:
demain montagne, neige et plus de numérique
donc si j'oublie bonne année a tous
 
Rebonjour les amis,

Bonne année à tous. Et je suppose que vous êtes déjà au courant de cette nouvelle faille Thunderstrike :

http://www.gridam.com/2014/12/thunderstrike-une-faille-qui-utilise-les-ports-thunderbolt-des-mac/

http://www.linformatique.org/thunderstrike-la-faille-de-tous-les-dangers-qui-cible-les-mac/

Encore une affaire à suivre de très près.

Je relève :

Mis au courant, Apple a donc revu son processus de démarrage pour ses nouveaux modèles et préparerait une mise à jour pour les anciens.