Les Mac sont-ils vulnérables au bogue shellshock de Bash?

bateau à cheveux

Les Mac sont-ils vulnérables au bogue shellshock de Bash?


Red Hat a récemment annoncé un bogue majeur lié à la sécurité dans le shell Bash. Certains l’appellent le bug « shellshock ». Étant donné que OS X est construit à partir d’Unix, est-il vulnérable aux attaques qui exploitent ce bogue?

En tant qu’utilisateur final, dois-je m’inquiéter d’une solution immédiate? Ou est-il préférable d’attendre une mise à jour officielle du logiciel d’Apple?


marque

Pour voir quelles actions affectent OSX, voir security.stackexchange.com/questions/68123/…

bateau à cheveux ♦

Mise à jour de la question, donc c’est moins dupe et plus une demande de conseil pour les laïcs.

À

Apple a publié un correctif maintenant: support.apple.com/kb/DL1769

Réponses


 JakeGould

Oui, vous êtes techniquement vulnérable. Donc, si vous avez envie de paniquer ou de facturer un client paniqué pour quelques heures de travail de panique, allez-y!

Mais la réalité est que si vous n’autorisez pas l’accès SSH à partir de connexions à distance ou d’un serveur Web qui exécute des scripts côté serveur, vous n’êtes pas à risque. Vous n’êtes vraiment vulnérable que si quelqu’un que vous ne connaissez pas peut accéder à distance à votre machine et le faire d’une manière où une commande Bash peut être exécutée.

Cela signifie que votre Mac de bureau – qui n’exécute vraiment aucune application serveur d’aucune sorte – ne présente aucun risque sérieux. Je suis prêt à manger ici une «tarte humble» proverbiale, mais je ne pense pas que la majorité des utilisateurs de Mac seront en danger à la fin de la journée.

Ce problème concerne donc principalement les administrateurs système sur les serveurs Mac OS X et Unix / Linux exposés au monde, et non les utilisateurs de bureau qui n’activent pas le partage SSH.

Il existe peut-être un risque de création d’un logiciel malveillant ou d’un virus Mac pour exploiter ce risque, mais j’en doute.

EDIT: Et juste pour expliquer comment ce problème – à mon humble avis – n’est pas vraiment un problème pour la plupart des utilisateurs moyens, oui, je peux exécuter la commande suivante à partir de bash sur Mac OS X 10.9.5:

 env x = '() { :;}; echo vulnerable'  bash - c 'echo hello' 

Et je vois ceci:

 vulnerable hello 

Devine quoi? Ce n’est terrifiant que si vous n’y réfléchissez pas rationnellement. Je devais déjà être connecté à mon Mac pour même ouvrir le terminal. Et pour annuler ce que j’ai dit à propos de SSH ci-dessus, pour arriver au point où je peux exécuter ce test même si SSH est activé, je devrai toujours être connecté pour commencer. Et puis – disons que j’y accède via SSH – la commande ne me permet pas de faire quoi que ce soit au-delà de mes droits d’utilisateur normaux tels que celui-ci:

 env x = '() { :;}; echo vulnerable'  bash - c 'cat /etc/ssh_host_rsa_key' 

Ce qui signifie que si vous êtes vraiment vulnérable à l’exploitation par ce piratage, votre sécurité de base sur le système devrait être si compromise que le fait que bash ait un défaut soit vraiment le moindre de vos problèmes.

Il s’agit d’une préoccupation liée à un problème global de contrôle et de droits, car elle pourrait permettre un accès involontaire, car le comportement dépasse les normes attendues. Mais à mon humble avis, ce n’est pas un risque à égalité avec OpenSSL ou la variété jardin «laissez-moi laisser mon mot de passe sur une note collée sur mon écran» risque.

À la fin de la journée, je corrige toujours tous mes serveurs Linux / Unix que je lance en tant que procédure standard. Et je me ferai un plaisir de patcher les Mac que je gère une fois qu’un correctif sera disponible. Mais pour une utilisation pratique au quotidien, je me sens bien de ne pas m’inquiéter à ce sujet car je ne comprends pas comment une faille qui ne permet pas de privilèges utilisateur élevés s’ajoute à rien.

MISE À JOUR: Mot officiel d’Apple publié ici ; accent sur le mien:

« La grande majorité des utilisateurs d’OS X ne sont pas exposés aux vulnérabilités de bash récemment signalées », a déclaré un porte-parole d’Apple à iMore. « Bash, un shell de commande UNIX et un langage inclus dans OS X, présente une faiblesse qui pourrait permettre aux utilisateurs non autorisés de gagner à distance des gains contrôle des systèmes vulnérables. Avec OS X, les systèmes sont sécurisés par défaut et ne sont pas exposés aux exploits à distance de bash, sauf si les utilisateurs configurent des services UNIX avancés. Nous travaillons pour fournir rapidement une mise à jour logicielle à nos utilisateurs UNIX avancés. »

Traduction: Qu’est-ce que j’ai dit ci-dessus à propos d’un problème de serveur et non d’un problème de client? Exactement.

UNE MISE À JOUR FINALE: Pour tous ceux qui ont du mal à compiler à partir des sources, au 29 septembre, Apple a officiellement publié des correctifs pour Mac OS X 10.9.5, 10.8.5 ainsi que 10.7.5:

ENCORE UNE AUTRE MISE À JOUR FINALE: Et maintenant, Apple vient de publier une mise à jour de sécurité combinée qui inclut également la mise à jour bash !

Remarque: la mise à jour de sécurité 2014-005 inclut le contenu de sécurité de la mise à jour 1.0 d’OS X bash

Ian C. ♦

« ou un serveur Web qui exécute des scripts côté serveur » – ou faire exécuter une application, en écoutant sur un port ouvert qui permet d’effectuer des appels RPC qui finissent par exécuter des commandes shell. Cela pourrait être un certain nombre de choses car il existe de nombreuses applications standard qui font leur RPC. Je pense que cette réponse est très naïve. Il est très facile «d’exécuter un serveur Web» par inadvertance au cours de l’exécution d’une application qui fait quelque chose de type client-serveur.

JakeGould

@IanC. Pouvez-vous fournir un exemple où OS X serait vraiment vulnérable? Par exemple, quelque chose comme WebEx ou GotoMeeting se rapprocherait-il même des capacités de Bash? Le fait étant que je ne peux pas penser à un scénario simple d’OS X qui exposerait vraiment les choses. Peut tu?

lbutlr

Le compte invité n’est pas disponible pour ssh. En fait, il n’est même pas possible de le mettre à la disposition de ssh, IIRC. Le fait est que pour la grande majorité des utilisateurs d’OS X, la vulnérabilité bash n’est pas du tout un problème. Pour ceux d’entre nous où c’est un problème, nous devons recompiler bash dès qu’un correctif testé est disponible, mais ce n’est pas le cas actuellement.

JakeGould

@IanC. D’accord, juste des exemples. Mais vous manquez toujours le point: comment peut-on exploiter une telle vulnérabilité dans chaque exemple que vous fournissez? Dans chaque cas, un utilisateur aurait besoin d’accéder au système pour commencer et ensuite quoi? Je ne suis pas désinvolte à ce sujet mais je ne comprends toujours pas quel serait le risque? Quelqu’un, par exemple, devrait se frayer un chemin à travers l’API Plex pour ensuite faire quoi exactement en bash pour faire quelque chose en dehors des droits d’utilisateur et des privilèges d’accès normaux?

JakeGould

@danielAzuelos « Tout le monde est vulnérable tant que le compte invité est ouvert: [! » Le compte invité n’a rien à voir avec bash . La peur est donc basée sur quoi exactement? De plus, même si le compte invité est ouvert et que bash est utilisable, quoi? D’après ce que je vois, une supposition utilisant cet exploit n’aurait pas de privilèges élevés ou quoi que ce soit même proche de cela. Sérieusement, je suis prêt à revenir sur ma position, mais cela ressemble plus à une panique basée sur peu de choses alors qu’OpenSSL était un vrai problème.


 Chris Aitchison

Oui!

Tapez ceci dans votre coque

 env x = '() { :;}; echo vulnerable'  bash - c 'echo hello' 

S’il dit vulnerable alors vous êtes vulnérable.

Si ça dit

 bash :  warning :  x :  ignoring function  definition attempt bash :  error importing function  definition for   `x' hello 

alors tu es bon.

Modifier: lien vers le correctif

bateau à cheveux ♦

Merci. J’ai mis à jour la question – si nous constatons que nous sommes vulnérables, comment un utilisateur Mac peut-il y remédier?

JakeGould

@abbyhairboat Publié ma réponse. À moins que vous exécutiez un serveur exposé au monde extérieur, il n’y a aucun risque pratique. Les administrateurs de serveur sont ceux qui doivent s’inquiéter à ce sujet.

Daniel Azuelos

→ abby: veuillez consulter cette réponse connexe: apple.stackexchange.com/a/146851/22003 .

Trane Francks

Essayez cet env X="() { :;} ; echo busted" /bin/sh -c "echo completed" – Même après avoir patché mon système, celui-ci crache un ‘busted’ sur la ligne de commande. Bah.

ismail

@Mark non, zsh est sûr. vous devez remplacer « bash -c » par « zsh -c » pour le tester.


 Daniel Azuelos

En tant qu’utilisateur final , vérifiez que:

  • votre compte invité est désactivé:

      Préférences système> Utilisateurs et groupes> Utilisateur invité
    
  • votre accès ssh est désactivé:

      Préférences Système> Partage> Connexion à distance
    

Par défaut, ils sont tous deux désactivés sur Mavericks.

En tant qu’utilisateur final , il est plus sûr d’attendre une mise à jour de sécurité officielle d’Apple corrigeant cette vulnérabilité bash .

Josh

Ce ne sont pas pertinents. L’un ou l’autre, par leur nature même, accorde aux utilisateurs l’accès à l’exécution de commandes sur le système, donc si vous les avez activés, vous avez l’intention d’autoriser les utilisateurs à exécuter des commandes. Le bogue Shellshock est un moyen pour les utilisateurs que vous n’aviez pas l’ intention d’exécuter des commandes pour pouvoir le faire, par exemple un utilisateur du serveur Web que vous exécutez. Donc, votre réponse devrait dire « Désactiver le partage Web » (mais ce n’est qu’une chose à vérifier)

minopret

Je suis ennuyé, Apple n’a pas conseillé de désactiver ces paramètres. Qui leur permettrait? Je voudrais. Je suis un utilisateur Mac depuis 1986, un développeur d’applications Web à temps plein (donc ssh est ma vie) et un père (donc un compte invité pour les enfants n’est pas une si mauvaise idée). Je connais beaucoup de gens qui sont comme moi de cette manière qui utilisent des ordinateurs portables Apple. Vous voulez nous perdre? Laisser cette vulnérabilité ouverte est un bon moyen.


 Jeff Burdges

Toutes les machines Mac OS X sont techniquement vulnérables à «Shellshock», jusqu’à ce qu’Apple publie une mise à jour de sécurité qui corrige bash, mais ..

Votre question devrait être: Puis-je être piraté à distance?

Il y a tellement de logiciels qui utilisent distraitement bash que répondre à cette question est extrêmement difficile. Si vous êtes inquiet, je suggérerais plusieurs modifications dans les System Preferences pour empêcher les exploits à distance:

  • Désactivez TOUS les services de partage sous Préférences de partage.
  • Activez le pare-feu sous Sécurité et confidentialité.

Si vous êtes particulièrement inquiet, appuyez sur le bouton d’options du FirewallFirewall pour:

  • Décochez Automatically allow signed software to receive incoming connections .
  • Cochez Block all incoming connections .

Il y a toujours une chance respectable que vous soyez vulnérable à une attaque de niveau en utilisant DHCP, Bonjour, etc., mais si vous avez besoin d’un autre service, vous pouvez évidemment le laisser fonctionner pendant que vous espérez qu’il ne sera pas exploité. Et vous devrez également laisser le pare-feu plus ouvert. Ce sera probablement bien si votre machine vit derrière un autre pare-feu.

Existe-t-il également des attaques par escalade de privilèges locales activées par «Shellshock?» Oui, presque sûrement. Je ne m’inquiéterais pas, car Mac OS X a suffisamment d’attaques similaires. Apple ne corrige pas rapidement les bogues d’élévation des privilèges locaux. Et Apple les crée fréquemment avec les services compatibles avec Apple Script. Supposez simplement que toutes les machines Mac OS X sont toujours vulnérables aux attaques locales. Si vous devez assister à des conférences de hackers comme DEFCON, achetez-vous une box Linux à cet effet.

Mise à jour: Il existe des instructions pour recompiler votre propre bash fixe et d’ autres questions abordées pour le faire également. Je le ferai moi-même, mais à mon humble avis, c’est exagéré si vous n’exécutez aucun serveur et que le pare-feu d’Apple reste activé de toute façon.

Mise à jour: Si vous êtes à l’aise avec l’utilisation du terminal, un programme appelé execsnoop mentionné ici vous permettra de tester si bash est généralement appelé par les processus de votre serveur. Ce n’est pas une solution miracle puisque le processus serveur peut appeler bash uniquement dans des situations inhabituelles, mais cela vous donnera une bonne idée.

Enfin, Apple n’est pas très bon pour corriger les vulnérabilités de sécurité, mais ils sont bons en relations publiques, donc cela sera corrigé relativement rapidement. Il est donc raisonnable de penser « Je n’ai pas besoin de courir plus vite que l’ours, je n’ai besoin que de courir plus vite que le grand nombre de serveurs facilement exploitables sur Internet ». 🙂

Jeff Burdges

Comment sais-tu ça? L’avis initial était un client DHCP vulnérable. Et de nombreux articles supposent que les clients DHCP de Mac OS X et / ou iOS pourraient être vulnérables. Tous les serveurs doivent être considérés comme vulnérables, sauf preuve contraire.

Trane Francks

@JeffBurdges, OS X n’a ​​pas utilisé d’exécution shell avec DHCP depuis 10.3, et avant que bash n’ait pas été installé sur le système. DHCP sur OS X n’est tout simplement pas un problème avec Shellshock. (Une chose de moins à s’inquiéter. :))

Daniel Azuelos

→ Jeff: veuillez considérer: strings /usr/libexec/bootpd | egrep '/bin|bash' strings /usr/libexec/bootpd | egrep '/bin|bash' et nm -a /usr/libexec/bootpd | egrep 'fork|exec' nm -a /usr/libexec/bootpd | egrep 'fork|exec' . En lisant ces sorties de commandes sur différentes versions de MacOS X, vous pourriez reconsidérer votre analyse des risques en raison de dhcpd sur MacOS X… mais celle-ci seule :(.


 Thomas Jones

J’ai créé cet outil dès que j’ai entendu parler de cette vulnérabilité. Il vous fournira un lien vers un article pour patcher votre shell si l’outil détermine que vous êtes vulnérable.

Nécessite Mac OS X 10.6 et supérieur.

Joe

Peut-être que c’est juste moi … mais l’idée d’exécuter du code d’une personne aléatoire pour tester un exploit semble être une très mauvaise idée quand vous pouvez tout aussi facilement coller une chaîne (c’est clairement exécuter le test et rien de plus) dans un fenêtre de terminal.

Thomas Jones

Je suis d’accord, c’est pourquoi la source est sur code.google.com/p/shellshock-check

Thomas Jones

Parfois, cependant, il peut offrir une facilité d’utilisation pour tester plusieurs systèmes.

Albert Godfrind

Je ne vois pas l’avantage de cette chose. Vérifier la vulnérabilité est beaucoup plus facile en collant une simple ligne de commande dans la fenêtre du terminal.

Thomas Jones

Cependant, lors du test de plusieurs machines, en particulier dans mon cas, car c’est ce que je fais, il est beaucoup plus facile de mettre un lecteur flash et d’ouvrir Shellshock Check.app que d’ouvrir Safari, de rechercher la commande bash pour vérifier, puis d’ouvrir Terminal, de coller cela puis appuyez sur Entrée. Il est beaucoup plus rapide de brancher un lecteur flash et d’ouvrir une application.

 

-bash:, #au, #de, Bogue, Les, Mac, Shellshock, sont-ils, vulnérables?

 

wiki

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *