Пользователь
0,0
рейтинг
15 января в 00:54

Разработка → В клиенте OpenSSH обнаружена серьёзная уязвимость CVE-2016-0777


Сегодня стало известно о новой уязвимости в клиенте OpenSSH получившей идентификаторы CVE-2016-0777 и CVE-2016-0778. Ей подвержены все версии программы от 5.4 до 7.1.

Обнаруженный баг позволяет осуществить атаку, приводящую к утечке приватного ключа. Аутентификация ключа сервера предотвращает атаку типа man-in-the-middle, так что злоумышленникам понадобится сначала получить доступ к машине, на которую вы пытаетесь зайти. Хотя, при подключении к машине впервые, не сверяя ключ, MITM возможен.

До тех пор пока вы не обновите уязвимые системы рекомендуется использовать следующий фикс:
echo -e 'Host *\nUseRoaming no' >> /etc/ssh/ssh_config

Обновления для различных ОС уже выходят, в том числе выпущена portable версия OpenSSH 7.1p2.

Клиент OpenSSH версий от 5.4 до 7.1 содержит код экспериментальной функции «roaming», позволяющей продолжать сессии. Серверная часть этой функциональности никогда не была опубликована, но существующий код клиента уязвим — злоумышленники могут получить часть памяти клиентской машины, содержащую приватный ключ. По умолчанию эта функция включена, поэтому узявимость достаточно серьёзна.

В общих чертах серьёзность ситуации описал пользователь patio11 в комментариях на Hacker News:
Немедленно примените фикс и обновите уязвимые системы, как на ваших рабочих машинах так и внутри вашей инфраструктуры — везде, где используется SSH. А использоваться он может в очень внезапных местах.

SSH спроектирован так, что если вы подключитесь к хосту злоумышленника, то хост узнает лишь ваш публичный ключ, но ни в коем случае не приватный. Данная уязвимость позволяет украсть ваш приватный ключ. Вы можете подумать — «я подключаюсь только к своим собственным серверам, так что я в безопасности» — но если в будущем злоумышленники получат доступ к одной единственной системе то они смогут использовать её чтобы украсть ваш приватный ключ и использовать его для доступа к остальным частям вашей инфраструктуры.

Таким образом, ваш личный фотоблог на Digital Ocean может стать потенциальной дырой в инфраструктуру вашей организации, потому как многие используют один и тот же приватный ключ.

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


Mac OS X


В homebrew и macports уже опубликованы пропатченные версии, для обновления выполните:
# Homebrew
brew update
brew install openssh

# MacPorts
port selfupdate
port install openssh


Linux / FreeBSD


Патчи уже готовы и скоро станут доступны в пакетных менеджерах, до момента обновления рекомендуется отключить функцию «roaming»:
echo -e 'Host *\nUseRoaming no' >> /etc/ssh/ssh_config

Так же вы можете использовать свежую portable версию.

Windows


Пользователи PuTTY в безопасности, пользователям OpenSSH под Cygwin следует использовать свежую portable версию.

Подробное описание уязвимости (англ.)
Заречнев Арсений @evindor
карма
41,0
рейтинг 0,0
Пользователь
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (29)

  • +5
    Обнаруженный баг позволяет осуществить атаку типа man-in-the-middle, приводящую к утечке приватного ключа.
    Нет, не позволяет.
    В той же цитате с HN, которую вы привели указано, что эксплуатировать уязвимость можно только с уже скомпрометированного вашего сервера.
    Читайте внимательно анонс:
    The authentication of the server host key prevents exploitation by a man-in-the-middle, so this information leak is restricted to connections to malicious or compromised servers.
    (хотя, при подключении к машине впервые не сверяя ключ, MITM возможен)

    Вот здесь подробности.
    • 0
      И правда, спасибо за поправку.
  • +4
    'Host *' не обязательна. Достаточно разместить 'UseRoaming no' выше частных, если они есть, директив 'Host '.
    • 0
      В общесистемном обычно нету частных.

      У меня там уже вверху «Host *», так что тоже необязательно, но это уже микрооптимизация конфига, которая щас меньшее зло ))
  • +2
    brew install openssh

    brew install homebrew/dupes/openssh
    
    • 0
      И так и так работает.
  • +14
    Допишите в заголовок «клиенте»:

    • В OpenSSH клиенте обнаружена серьёзная уязвимость CVE-2016-0777
  • +2
    Вот отличный подход: сначала исправление проблемы, рекомендации по обходу, если обновиться сложно/невозможно, а потом публикация. А не: сначала даём на всеобщее обозрение, а потом думаем как исправлять/обходить.
    • 0
      Товарищи минусующие, прошу объяснить причину вашего негодования? Как минимум я выразил уважение, что автору данной статьи, что автору (косвенно) исходного бюллетеня, что информация попала в публичный доступ после того, как были приняты меры по исправлению и поиску обходных путей решения проблемы. К примеру, в случае недавнего обсуждения проблемы в FFmpeg, получилось с точностью до наоборот.

      ЗЫ хотя да, построение текста получилось сумбурным.
      • 0
        Уязвимость слишком серьезная, чтобы о ней молчать. Это как hearthbleed, о котором сразу раструбили
        • –1
          Я не спорю!

          Но смотри, ситуация (без привязки к конкретному софту, вообще), найдена проблема, о ней знает какое-то конечное число людей. Пусть даже среди ни есть недобросовестные, которые её эксплуатируют в своих корыстных целях. Теперь эту проблему публикуют в открытом доступе, но не дают никакой рекомендации, что делать. В результате выбор невелик: или вообще не пользоваться софтом, или любой (ну или почти, если говорить про проблему в исходном тексте) скрипт-киддер теперь может ей воспользоваться. Или другой вариант: беглое изучение в закрытом кругу, поиск вариантов быстрого закрытия проблемы, в идеале — патч и выпуск обновления, и только после этого публикация в открытом доступе. По мне, так второй вариант лучше. Действие по первому варианту, я, с натяжкой, допускаю только в случае, если разработчики не шевелятся, игнорируют.
          • +2
            но не дают никакой рекомендации

            Дают же

            любой скрипт-киддер теперь может ей воспользоваться

            Всё-же сложно такой шуткой воспользоваться без определенных навыков

            патч и выпуск обновления, и только после этого публикация в открытом доступе

            А теперь представьте себе компанию, которая каждый день защищается от сотен тысяч попыток проникновения, терпит и вполне успешно защищается известными практиками. Но один из хакеров покупает эту 0-day уязвимость за немалые деньги и наконец-то проникает в эту организацию, которая еще не в курсе таких выкрутасов.
            Я к чему это всё говорю — при любом варианте развития будут жертвы, и очень сложно однозначно утверждать, при каком варианте жертв будет меньше.
          • 0
            В первом варианте у пользователей хотя бы есть выбор.
          • +3
            Теперь эту проблему публикуют в открытом доступе, но не дают никакой рекомендации, что делать. В результате выбор невелик: или вообще не пользоваться софтом, или любой (ну или почти, если говорить про проблему в исходном тексте) скрипт-киддер теперь может ей воспользоваться.
            К подобным новостям пошаговых инструкций по использованию уязвимости, как правило, не прилагают. Что несколько повышает порог вхождения.
            Но самое главное — предупреждён, значит вооружен. Даже если это 0-day уязвимость и никто в мире пока ещё не знает как это исправлять, лучше знать заранее и иметь возможность как минимум отключить уязвимую часть, чтобы обезопасить себя, чем потом внезапно обнаружить, что поздно пить боржоми.
            • 0
              Про пошаговые инструкции не говорю. Про недавний FFmpeg появилась заметка на SecurityLab с резолюцией: решения нет. Ну как нет? Можно же было пересобрать без поддержки протокола concat и/или hls. Тем временем авторы приняли и доработали фикс в части белых адресов в hls и выпустили обновления во всех поддерживаемых линейках.
        • +2
          Да, в случае Heartbleed, можно было, по крайней мере, пересобрать без поддержки Heartbeat. Это один из вариантов WA.
      • +1
        Вы по сути пропагандируете Security through obscurity, я считаю, что это вредно. В крайнем случае, правильнее дать людям возможность отключить систему совсем (например, удалить ffmpeg на время). Уязвимость можно (по крайней мере временно) «закрыть» всегда путём отказа от части функциональности либо путем добавления «внешних» слоёв — ограничения доступа к уязвимым системам, например с помощью фаервола/антивируса и т.п.
        • 0
          У меня не возникло впечатления, что это про security through obscurity. Скорее про responsible disclosure, когда про уязвимость сообщили авторам, они успели принять меры, и только потом уязвимость была опубликована с подробным описанием.
          • 0
            Если авторы в сроки, сопоставимые со сроками на публикацию описания, не могу предложить решение — лучше публиковать, указывая «отключите наш сервис» в качестве решения. В противном случае это попытка полагаться на security through obscurity, когда obscurity никакой уже и нет. Пользы от совета «выключите наш сервис, он уязвим» больше, чем от попыток скрыть на время наличие уязвимости. Потому что по-нормальному защита всегда обеспечивается эшелонированием — именно для того, что бы в случае наличия проблем в одном из эшелонов можно было положиться на другие, а тем временем решать проблемы (создавать новый эшелон защиты взамен утраченному либо латать старый). Если же уязвимость скрывают, то эшелонированная защита не спасает т.к. все эшелоны могут оказаться скомпрометированными, а ответственное лицо даже не узнает об этом.
            • 0
              Собственно, при любом раскладе хорошо сначала сообщить авторам — больше шансов получить более удовлетворительный ответ нежели «выключите наш сервис совсем» (например: «пересоберите без поддержки Heartbeat»), если ответа нет, то резонно действовать публично. Пересборку может выполнить и конечный потребитель, при наличии навыков, и поддерживающий пакета в дистрибутиве и выпустить как обновление безопасности.
  • 0
    В  macports тоже есть обновление:
    $ port search openssh
    openssh @7.1p2 (net)
        OpenSSH secure login server
    

    port install openssh
    
  • +1
    Сильно громкий заголовок, все подробности тут есть + pov: https://www.qualys.com/2016/01/14/cve-2016-0777-cve-2016-0778/openssh-cve-2016-0777-cve-2016-0778.txt
    • +2
      Ссылку на кволис уже давали ранее, сорри. Если б заголовок соответствовал реальному уровню опасности — была бы отличная идея для хонейпотов )
  • 0
    Фикс для дебиана:
    проверяем версию sshd
    telnet 127.0.0.1 12345 (12345 — кастомный порт для ssh, если меняли или пишите 22, если ничего не меняли)
    Trying 127.0.0.1...
    Connected to 127.0.0.1.
    Escape character is '^]'.
    SSH-2.0-OpenSSH_6.0p1 Debian-4+deb7u3
    ^C
    Connection closed by foreign host
    


    1) качаем http://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-7.1p2.tar.gz
    2) распаковываем
    3) обновляем apt apt-get update
    4) ставим библиотеки apt-get install zlib1g-dev libssl-dev libpam0g-dev libkrb5-dev (дефолтный sshd, который идет с дебианом собран с pam и с kerberos)
    5) конфигурируем ./configure --with-pam --with-kerberos5 --prefix=/usr --sysconfdir=/etc/ssh, сие ставится в usr (!) как дефолтный sshd у меня на сервере, и хранит конфиги в /etc/ssh (!) тоже как оригинальный sshd у меня на сервере — пишу жирным, так как вероятно у кого-то debian-netinst ставит или ставил в другое место, вдруг!
    6) make, если не выдало ошибок, то пункт #7. Если ошибки есть, то make clean, затем google и пункт #1 с новыми библиотеками + комментарий сюда, что именно нет встало.
    7) make install. Если ошибки есть, то они скорее всего из-за того, что у вас в конфиге. Делаете make clean, топаете в гугл, смотрите что у вас в конфиге не так (=чего не было указано при конфигурации), затем с первого пункта.
    8) если все ок, перезапускаете сервис service ssh restart
    9) снова проверяете версию
    telnet 127.0.0.1 12345
    Trying 127.0.0.1...
    Connected to 127.0.0.1.
    Escape character is '^]'.
    SSH-2.0-OpenSSH_7.1
    ^C
    Connection closed by foreign host.
    


    Вот и все.
    • +1
      А ssh -V — выдаст версию клиента!
    • +3
      Ужас какой. Зачем пересобирать-то? В security-репозитории версия с патчем уже есть какое-то время.
      • 0
        Когда я проверял и хотел все сразу актуализировать, apt-get install openssh-server openssh-client выдавал те же самые, что у меня уже стояли (на 7 и 8 дебианах).
        Поэтому решил с сайта слить и пересобрать на всех.
        • +5
          У вас security-репозитории-то подключены?
          А вообще, пересобирается оно сделающим образом:
          apt-get source openssh-server
          apt-get build-dep openssh-server

          Находим необходимый патч, далее:
          quilt import your-patch.patch
          dpkg-buildpackage
          

          Все, у нас рядом лежат собранные .deb'ы.
          • 0
            Да, вот с виртуалки:
            deb http://security.debian.org/ wheezy/updates main
            deb-src http://security.debian.org/ wheezy/updates main
            
            # wheezy-updates, previously known as 'volatile'
            deb http://ftp.de.debian.org/debian/ wheezy-updates main
            deb-src http://ftp.de.debian.org/debian/ wheezy-updates main
            

            Спасибо за примеры цивилизованных апдейтов:)

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.