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


59

Chapeau rouge récemment a annoncé un bug majeur lié à la sécurité dans le shell Bash. Certains l'appellent le bug "shellshock". OS X étant basé sur 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 pour moi d'attendre une mise à jour logicielle officielle d'Apple?



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

Mise à jour de la question afin que ce soit moins dupe et plus une demande de conseil pour laïcs.
hairboat

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

Réponses:


46

Oui, vous l'êtes techniquement vulnérable. Donc, si vous avez envie de paniquer ou de facturer quelques heures de travail paniqué à un client paniqué, foncez!

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

Cela veut dire que votre Mac de bureau - qui n’exécute aucune application serveur - n’expose aucun risque sérieux. Je suis prêt à manger une "tarte humble" proverbiale ici, mais je ne pense pas que la majorité des utilisateurs de Mac seront exposés à un risque à la fin de la journée.

Ce problème concerne donc principalement les administrateurs système sous Mac OS X & amp; Les serveurs Unix / Linux exposés au monde, pas les utilisateurs de bureau qui n'activent pas le partage SSH.

Il existe peut-être un risque marginal qu'un logiciel malveillant ou un virus Mac soit créé pour exploiter ce risque, mais j'en doute.

MODIFIER: Et juste pour expliquer en quoi ce problème est - à mon humble avis - pas vraiment un problème pour la plupart des utilisateurs moyens, oui je peux exécuter la commande suivante depuis 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 de manière rationnelle. Je devais déjà être connecté à mon Mac pour même ouvrir le terminal. Et pour nier ce que j'ai dit à propos de SSH ci-dessus, et même pour arriver au point où je peux exécuter ce test même si SSH est activé, je dois toujours être connecté pour commencer. Et ensuite, disons que j’ai l’accès via SSH, la commande ne me permet pas de faire AUCUNE chose au-delà de mes droits d’utilisateur normaux, tels que:

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

Cela signifie que si vous êtes vraiment vulnérable à être exploité par ce piratage, votre sécurité principale sur le système devra être tellement compromise que le fait que bash a une faille est vraiment le moindre de vos problèmes.

Ceci est une préoccupation d'un contrôle global & amp; question de droits comme le potentiel permettre un accès involontaire, car le comportement dépasse les normes attendues. Mais à mon humble avis, ce n’est pas un risque équivalent à OpenSSL ou à la variante jardinage «laissez-moi laisser mon mot de passe sur une note collée à l’écran», de risques.

À la fin de la journée, je suis toujours en train de patcher tous mes serveurs Linux / Unix que je lance en tant que procédure standard. Et je mettrai volontiers à jour les Mac que je gère une fois le correctif publié. Mais pour une utilisation quotidienne pratique, je me sens bien de ne pas m'inquiéter de cela, car je ne comprends pas comment une faille qui ne permet pas des privilèges d'utilisateur élevés ajoute à rien.

METTRE À JOUR: Mot officiel d'Apple posté ici ; mon accentuation:

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

Traduction: Ce que j’ai dit plus haut à propos du fait qu’il s’agit d’un problème lié au serveur pas un problème de client? Exactement.

UNE MISE À JOUR FINALE: Pour ceux qui ont du mal à compiler leurs sources, le 29 septembre, Apple a officiellement publié les correctifs pour Mac OS X 10.9.5, 10.8.5 et 10.7.5:

ENCORE UNE AUTRE MISE À JOUR FINALE: Et maintenant, Apple vient de publier une mise à jour de sécurité combinée qui comprend le bash mettre à jour aussi bien !

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


7
"ou un serveur Web qui exécute des scripts côté serveur" - ou si une application est en cours d'exécution et écoute sur un port ouvert permettant d'effectuer des appels RPC qui exécutent des commandes shell. Cela pourrait être un certain nombre de choses car il y a beaucoup d'applications standard qui font leur RPC. Je pense que cette réponse est très naïve. Il est très facile de "faire tourner un serveur Web" par inadvertance lors de l'exécution d'une application qui fait quelque chose de type client-serveur.
Ian C.

3
@IanC. Pouvez-vous donner un exemple dans lequel OS X prêt à l'emploi serait vraiment vulnérable? Par exemple, quelque chose comme WebEx ou GotoMeeting s'approcherait-il des capacités de Bash? Le fait est que je ne peux pas penser à un simple scénario d'installation sous OS X qui exposerait réellement les choses. Peut tu?
JakeGould

8
Le compte invité est ne 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é de bash n’est pas un problème. Pour ceux d'entre nous qui rencontrent un problème, nous devons recompiler bash dès qu'un correctif testé est disponible, mais ce n'est pas le cas maintenant.
lbutlr

3
@IanC. Ok, juste des exemples. Mais vous manquez toujours le point: comment exploiter une telle vulnérabilité dans chaque exemple que vous fournissez? Dans chaque cas, un utilisateur doit avoir accès au système pour commencer avec & amp; alors quoi? Je ne suis pas désinvolte à ce sujet mais je ne comprends toujours pas le risque réel. Quelqu'un, par exemple, devrait se frayer un chemin à travers l’API Plex pour ensuite faire exactement ce que bash veut faire en dehors des droits d’utilisateur normaux & amp; privilèges d'accès?
JakeGould

6
@danielAzuelos "Tout le monde est vulnérable tant que le compte invité est ouvert: [!" Le compte invité n'a rien à voir avec bash. Donc, la peur est basée sur quoi exactement? De même, même si le compte invité est ouvert, & amp; en quelque sorte bash est utilisable, alors quoi? D'après ce que je vois, je suppose que l'utilisation de cet exploit n'aurait pas de privilèges élevés, ni rien de ce genre. Sérieusement, je suis prêt à reculer de ma position, mais cela ressemble plus à une panique basée sur pas beaucoup alors qu'OpenSSL était un réel problème.
JakeGould

37

Oui!

Tapez ceci dans votre shell

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

Si ça 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


4
Merci. J'ai mis à jour la question - si nous trouvons que nous sommes vulnérables, comment un utilisateur Mac peut-il résoudre ce problème?
hairboat

3
@abbyhairboat Posté ma réponse. Sauf si vous utilisez 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.
JakeGould

1
→ abby: veuillez voir cette réponse: apple.stackexchange.com/a/146851/22003 .
daniel Azuelos

2
Essaye ça env X="() { :;} ; echo busted" /bin/sh -c "echo completed" - Même après avoir corrigé mon système, celui-ci crache un 'éclaté' sur la ligne de commande. Bah.
Trane Francks

1
@ Mark Nope, zsh est en sécurité. vous devez remplacer "bash -c" par "zsh -c" pour le tester.
ismail

3

En tant que utilisateur final , regarde ça:

  • votre compte invité est désactivé:

    System Preferences > Users & Groups > Guest User
    
  • votre ssh l'accès est désactivé:

    System Preferences > Sharing > Remote Login
    

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

En tant que utilisateur final , il est plus sûr d'attendre qu'une mise à jour de sécurité officielle d'Apple corrige ce problème bash vulnérabilité.


1
Ce ne sont pas pertinents. De par leur nature même, les deux autorisent les utilisateurs à exécuter des commandes sur le système. Par conséquent, si vous les activez, il est de votre intention d'autoriser les utilisateurs à exécuter des commandes. Le bug Shellshock est un moyen pour les utilisateurs que vous n'a pas l'intention de pouvoir exécuter des commandes pour pouvoir le faire, E.G. 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)
Josh

Je suis ennuyé Apple n'a pas conseillé de désactiver ces paramètres. Qui leur permettrait? Je voudrais. Je suis un utilisateur de Mac depuis 1986, un développeur d’applications Web à plein temps (ma vie est donc ssh) 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, comme moi, utilisent les ordinateurs portables Apple. Tu veux nous perdre? Laisser cette vulnérabilité ouverte est un bon moyen.
minopret

2

Toutes les machines Mac OS X sont techniquement vulnérables à «Shellshock» jusqu'à ce que Apple publie une mise à jour de sécurité qui corrige bêta, mais ..

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

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

  • 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 Firewall bouton options pour:

  • Décocher Automatically allow signed software to receive incoming connections.
  • Vérifier Block all incoming connections.

Il y a toujours une chance respectable que vous soyez vulnérable à une attaque de niveau utilisant DHCP, Bonjour, etc., mais bon, 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. Tout ira bien si votre machine vit derrière un autre pare-feu.

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

Mettre à jour: Il y a des instructions pour recompiler votre propre bash fixe et une autre question couverte le faisant aussi. Je vais le faire moi-même, mais à mon humble avis, c'est exagéré si vous n'exécutez aucun serveur et laissez le pare-feu d'Apple activé de toute façon.

Mettre à jour: Si vous êtes à l'aise avec l'utilisation du terminal, il existe un programme appelé execsnoop mentionné ici cela vous permettra de vérifier si bash est généralement appelé par vos processus de serveur. Ce n'est pas une solution miracle, car le processus serveur peut appeler bash uniquement dans des situations inhabituelles, mais cela vous en donnera une bonne idée.

Enfin, Apple ne maîtrise pas très bien les vulnérabilités de sécurité, mais elles sont bonnes en relations publiques. Elles seront donc corrigées assez 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". :)


2
Il n'y a aucune chance que les Macs soient vulnérables à une attaque utilisant DHCP, car ils n'utilisent pas Bash.

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

1
Non, ils ne devraient pas l'être. c'est absolu FUD. Vous pouvez examiner à la fois le code source ouvert de l'implémentation DHCP de OS X et mesurer vous-même les appels système à vérifier.

3
@JeffBurdges, OS X n'a ​​pas utilisé shell exec avec DHCP depuis la version 10.3, et avant cela, bash n'était pas installé sur le système. DHCP sur OS X n’est tout simplement pas un problème avec Shellshock. (Une chose de moins à propos de laquelle s'inquiéter. :))
Trane Francks

1
→ Jeff: s'il vous plaît considérez: strings /usr/libexec/bootpd | egrep '/bin|bash' et nm -a /usr/libexec/bootpd | egrep 'fork|exec'. En lisant ces commandes sur différentes versions de MacOS X, vous pouvez revoir votre analyse de risque en raison de: dhcpd sur MacOS X… mais celui-ci seul :(.
daniel Azuelos

2

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

Nécessite Mac OS X 10.6 et plus.


3
C’est peut-être juste moi… mais l’idée de faire fonctionner le code d’une personne aléatoire pour tester un exploit semble tout simplement vraiment mauvaise idée quand vous pouvez tout aussi facilement coller une chaîne (il est clair que vous n'exécutez que le test), dans une fenêtre de terminal.
Joe

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

Je ne vois pas l'intérêt de cette chose. La vérification de la vulnérabilité est beaucoup plus facile en collant une simple ligne de commande dans la fenêtre du terminal.
Albert Godfrind

Lorsque je teste plusieurs machines, en particulier dans mon cas, comme je le fais, insérer un lecteur flash et ouvrir Shellshock Check.app est beaucoup plus simple que d’ouvrir Safari, il suffit de rechercher la commande bash pour vérifier, puis d’ouvrir Terminal, puis de le coller. puis appuyez sur Entrée. Il est beaucoup plus rapide de brancher un lecteur flash et d’ouvrir une application.
Thomas Jones
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.