Маки уязвимы к ошибке Bash shellshock?


58

Red Hat недавно объявила о серьезной ошибке безопасности в оболочке Bash. Некоторые называют это «ракушкой». Поскольку OS X основана на Unix, уязвима ли она для атак, использующих эту ошибку?

Как конечному пользователю, мне нужно беспокоиться о немедленном исправлении? Или мне лучше дождаться официального обновления программного обеспечения от Apple?



Чтобы увидеть , какие действия влияют на OSX см security.stackexchange.com/questions/68123/...
user151019

Обновил вопрос так, чтобы он был скорее не обманом, а скорее просьбой о совете для мирян.
прическа

1
Apple , выпустила исправление в настоящее время: support.apple.com/kb/DL1769
AT

Ответы:


46

Да, вы технически уязвимы. Так что, если вам хочется паниковать или выставить счет паниковавшему клиенту за несколько часов панической работы, сделайте это!

Но реальность такова, что если вы не разрешите доступ по SSH через удаленные соединения или веб-сервер, на котором выполняется сценарий на стороне сервера, вы не подвергаетесь риску. Вы по-настоящему уязвимы, только если кто-то, кого вы не знаете, может получить удаленный доступ к вашему компьютеру и сделать это таким образом, чтобы можно было выполнить команду Bash.

То есть ваш настольный Mac, на котором действительно не работают серверные приложения, не подвергается серьезному риску. Я готов съесть здесь какой-нибудь пресловутый «скромный пирог», но я не думаю, что большинство пользователей Mac будут подвергаться риску в конце дня.

Таким образом, эта проблема в основном касается системных администраторов на серверах Mac OS X и Unix / Linux, работающих в мире, а не пользователей настольных компьютеров, которые не разрешают совместное использование SSH.

Возможно, существует риск того, что вредоносное ПО или вирус Mac будут созданы для использования этого риска, но я сомневаюсь в этом.

РЕДАКТИРОВАТЬ: И просто чтобы прояснить, как эта проблема - по моему скромному мнению - на самом деле не проблема для большинства средних пользователей, да, я могу запустить следующую команду из bashMac OS X 10.9.5:

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

И я вижу это:

vulnerable
hello

Угадай, что? Это страшно, только если вы рационально не продумаете это. Я должен был уже войти в мой Mac, чтобы даже открыть терминал. И чтобы отрицать то, что я сказал о SSH выше, даже до того момента, когда я смогу выполнить этот тест, даже если SSH включен, мне все равно придется войти в систему для начала. И затем - скажем, я получаю доступ через SSH - команда не позволяет мне делать НИЧЕГО, кроме моих обычных прав пользователя, таких как эта:

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

Это означает, что если вы действительно уязвимы для того, чтобы быть взломанным этим хаком, ваша базовая безопасность в системе должна была бы быть настолько скомпрометирована, что bashнедостаток - это на самом деле наименьшая из ваших проблем.

Это является проблемой общего контроля и прав, поскольку это может привести к непреднамеренному доступу, поскольку поведение выходит за рамки ожидаемых норм. Но, по моему скромному мнению, это не риск наравне с OpenSSL или разновидностью сада «позвольте мне оставить свой пароль на заметке, прикрепленной к моему экрану».

В конце дня я все еще исправляю все свои серверы Linux / Unix, которые я запускаю как стандартную процедуру. И с радостью исправит Mac, которыми я управляю, как только выйдет исправление. Но для практического повседневного использования я чувствую себя нормально, не беспокоясь об этом, поскольку я не понимаю, как недостаток, который не допускает повышенных пользовательских привилегий, складывается во что-либо.

ОБНОВЛЕНИЕ: официальное сообщение от Apple, размещено здесь ; Акцент мой:

«Подавляющее большинство пользователей OS X не подвержены риску недавно обнаруженных уязвимостей bash, - заявил представитель Apple iMore. - У Bash, командной оболочки и языка UNIX, включенных в OS X, есть слабость, которая может позволить неавторизованным пользователям получать удаленный доступ. контроль уязвимых систем. В OS X системы по умолчанию безопасны и не подвергаются удаленному использованию bash, если пользователи не настроят расширенные службы UNIX. Мы работаем над тем, чтобы быстро предоставить обновление программного обеспечения для наших опытных пользователей UNIX ».

Перевод: Что я сказал выше о том, что это проблема сервера, а не проблемы клиента? Именно так.

ЗАКЛЮЧИТЕЛЬНЫЙ UDPATE: для тех, кто борется с компиляцией из исходного кода, по состоянию на 29 сентября Apple официально выпустила исправления для Mac OS X 10.9.5, 10.8.5, а также 10.7.5:

ДАЛЕЕ ДРУГОЕ ЗАКЛЮЧИТЕЛЬНОЕ ОБНОВЛЕНИЕ: И теперь, Apple, только что выпустила обновление комбинированной безопасности сегодня, которое также включает это bashобновление !

Примечание: Обновление безопасности 2014-005 включает в себя содержимое безопасности OS X bash Update 1.0


7
«или веб-сервер, на котором выполняются сценарии на стороне сервера» - или запустите приложение, прослушивающее открытый порт, который позволяет выполнять вызовы RPC, в результате чего выполняются команды оболочки. Это может быть любое количество вещей, так как существует множество стандартных приложений, которые выполняют RPC. Я думаю, что этот ответ очень наивен. Очень просто непреднамеренно «запускать веб-сервер» в процессе запуска приложения, которое делает что-то типа клиент-сервер.
Ян С.

3
@IanC. Можете ли вы привести пример, где OS X из коробки будет действительно уязвимой? Например, может ли что-то вроде WebEx или GotoMeeting приблизиться к возможностям Bash? Дело в том, что я не могу придумать простой сценарий установки OS X, который действительно раскрыл бы вещи. Ты можешь?
JakeGould

8
Гостевой аккаунт не доступен для ssh. На самом деле, даже невозможно сделать его доступным для ssh, IIRC. Дело в том, что для подавляющего большинства пользователей OS X уязвимость bash не является проблемой. Для тех из нас, у кого это проблема, мы должны перекомпилировать bash, как только будет доступно протестированное исправление, но это не сейчас.
lbutlr

3
@IanC. Хорошо, честные примеры. Но вы все еще упускаете суть: как можно использовать такую ​​уязвимость в каждом приведенном вами примере? В каждом случае пользователю потребуется доступ к системе для начала и что дальше? Я не обманываю это, но я все еще не понимаю, какой риск будет на самом деле? Кто-то, например, должен был бы проникнуть через Plex API, чтобы затем делать то, что именно в bash, чтобы делать что-то, выходящее за рамки обычных прав пользователя и прав доступа?
JakeGould

6
@danielAzuelos «Все уязвимы, пока открыт гостевой аккаунт: [!» Гостевой аккаунт не имеет ничего общего bash. Так на чем же основан страх? Кроме того, даже если гостевая учетная запись открыта и как-то bashпригодна для использования, что тогда? Судя по тому, что я вижу, использование этого эксплойта не имело бы повышенных привилегий или чего-то подобного. Серьезно, я готов отступить от своей позиции, но это больше похоже на панику, основанную на немногое, тогда как OpenSSL был реальной проблемой.
JakeGould

37

Да!

Введите это в вашей оболочке

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

Если это говорит, vulnerableто вы уязвимы.

Если это говорит

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

тогда ты хорош.

Изменить: ссылка на исправление


4
Благодарю. Я обновил вопрос - если мы обнаружим, что мы уязвимы, как пользователь Mac может это исправить?
Лодка

3
@abbyhairboat Написал мой ответ. Если вы не используете сервер, подверженный влиянию внешнего мира, практического риска нет. Администраторы сервера должны беспокоиться об этом.
JakeGould

1
→ Эбби: пожалуйста, смотрите этот связанный ответ: apple.stackexchange.com/a/146851/22003 .
дан

2
Попробуйте это env X="() { :;} ; echo busted" /bin/sh -c "echo completed"- даже после исправления моей системы, этот выкашливает «перебор» в командной строке. Ба.
Trane Francks

1
@ Марк Нет, Zsh безопасен. вам нужно заменить "bash -c" на "zsh -c", чтобы проверить это.
Исмаил

3

Как конечный пользователь , проверьте, что:

  • Ваш гостевой аккаунт отключен:

    Системные настройки> Пользователи и группы> Гость
    
  • Ваш sshдоступ отключен:

    Системные настройки> Общий доступ> Удаленный вход
    

По умолчанию они оба отключены на Mavericks.

В качестве конечного пользователя , это безопаснее ждать официального обновления безопасности Apple , фиксирующей эту bashуязвимость.


1
Это не имеет значения. Любой из них, по своей природе, предоставляет пользователям доступ к запуску команд в системе, поэтому, если они у вас включены, вы намерены разрешить пользователям запускать команды. Ошибка Shellshock - это средство для пользователей, для которых вы не собирались запускать команды, например пользователь веб-сервера, который вы запускаете. Итак, ваш ответ должен сказать «Отключить общий доступ к сети» (но это только одна вещь, чтобы проверить)
Джош

Я раздражен, что Apple не советовала отключать эти настройки. Кто бы им позволил? Я мог бы. Я пользователь Mac с 1986 года, постоянный разработчик веб-приложений (так что ssh - это моя жизнь) и папа (так что учетная запись гостя для детей не такая уж плохая идея). Я знаю много людей, которые похожи на меня в этих отношениях, которые используют ноутбуки Apple. Хотите потерять нас? Оставить эту уязвимость открытой - это хороший способ.
минопрет

2

Все компьютеры Mac OS X технически уязвимы для «Shellshock», пока Apple не выпустит обновление безопасности, которое исправляет bash, но ...

Ваш вопрос должен быть: можно ли взломать удаленно?

Существует так много программного обеспечения, которое bashрассеянно использует, что ответить на этот вопрос чрезвычайно сложно. Если вы беспокоитесь, я бы предложил несколько изменений System Preferencesдля предотвращения удаленных эксплойтов:

  • Отключите ВСЕ службы обмена в разделе «Настройки общего доступа».
  • Включите брандмауэр в разделе «Безопасность и конфиденциальность».

Если вы особенно обеспокоены, нажмите Firewallкнопку параметров, чтобы:

  • Снимите флажок Automatically allow signed software to receive incoming connections.
  • Проверьте Block all incoming connections.

Есть все еще респектабельный шанс того, что вы уязвимы для атаки уровня, использующей DHCP, Bonjour и т. Д., Но, если вам нужна другая служба, то, очевидно, вы можете оставить ее работающей, в то время как вы надеетесь, что она не будет использована. И вам нужно будет оставить брандмауэр более открытым. Скорее всего, будет хорошо, если ваша машина живет за другим брандмауэром.

Кроме того, существуют ли локальные атаки на повышение привилегий с помощью «Shellshock»? Да, почти наверняка. Я бы не стал беспокоиться, потому что в Mac OS X достаточно подобных атак. Apple не исправляет локальные ошибки повышения привилегий быстро. И Apple часто создает их с помощью сервисов Apple Script. Предположим, что все компьютеры Mac OS X всегда уязвимы для локальных атак. Если вам нужно посещать хакерские конференции, такие как DEFCON, тогда купите себе Linux-коробку для этой цели.

Обновление: есть инструкции по перекомпиляции вашего собственного исправленного bash и другие вопросы, описанные выше . Я сделаю это сам, но имхо, это излишне, если вы не запускаете никаких серверов и все равно включаете брандмауэр Apple.

Обновление: Если вы знакомы с терминалом использованием, есть программа под названием execsnoopупоминается здесь , что даст вам тест ли баш, как правило , вызываются вашими процессы сервера. Это не волшебная палочка, поскольку серверный процесс может вызывать bash только в необычных ситуациях, но это даст вам хорошую идею.

Наконец, Apple не очень хороша в исправлении уязвимостей безопасности, но они хороши в PR, так что это будет исправлено относительно быстро. Поэтому разумно подумать: «Мне не нужно работать быстрее, чем медведь, мне нужно работать только быстрее, чем огромное количество легко эксплуатируемых серверов в Интернете». :)


2
Нет шансов, что Маки уязвимы для атаки с использованием DHCP, так как он не использует Bash.

1
Откуда ты это знаешь? Первоначальный совет был уязвимым DHCP-клиентом. И многие статьи предполагают, что клиенты Mac OS X и / или iOS могут быть уязвимы. Все серверы должны считаться уязвимыми, если не доказано иное.
Джефф Берджес

1
Нет, они не должны быть; это абсолютное FUD. Вы можете проверить как открытый исходный код для реализации dhcp в OS X, так и измерить системные вызовы самостоятельно для проверки.

3
@JeffBurdges, OS X не использует shell exec с DHCP с 10.3, и до этого bash не был установлен в системе. DHCP на OS X просто не проблема с Shellshock. (Еще одна вещь, о которой стоит беспокоиться. :))
Trane Francks,

1
→ Джефф: пожалуйста, подумайте: strings /usr/libexec/bootpd | egrep '/bin|bash'а nm -a /usr/libexec/bootpd | egrep 'fork|exec'. Читая вывод этих команд в разных версиях MacOS X, вы можете пересмотреть свой анализ рисков, связанных с dhcpdMacOS X… но только этот :(.
dan

2

Я сделал этот инструмент, как только услышал об этой уязвимости. Он предоставит вам ссылку на статью для исправления вашей оболочки, если инструмент определит вашу уязвимость.

Требуется Mac OS X 10.6 и выше.


3
Может быть, это только я ... но идея запуска кода какого-то случайного человека для проверки на эксплойт кажется просто очень плохой идеей, когда вы можете так же легко вставить строку (это явно только запуск теста и ничего более) в окно терминала.
Джо

Я согласен, именно поэтому источник находится на code.google.com/p/shellshock-check
Томас Джонс,

Иногда, однако, он может предложить простоту использования для тестирования нескольких систем.
Томас Джонс

Я не вижу пользы от этой вещи. Проверить уязвимость гораздо проще, вставив простую командную строку в окно терминала.
Альберт Годфринд

Однако при тестировании нескольких машин, особенно в моем случае, так как это то, что я делаю, вставить флэш-диск и открыть Shellshock Check.app гораздо проще, чем открыть Safari, посмотреть команду bash для проверки, затем открыть терминал и вставить его. команду и затем нажмите Enter. Гораздо быстрее подключить флешку и открыть одно приложение.
Томас Джонс
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.