Сегодня стало известно о новой уязвимости в клиенте 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 версию.
Подробное описание уязвимости (англ.)
Комментарии (29)
J_o_k_e_R
15.01.2016 02:37+4'Host *' не обязательна. Достаточно разместить 'UseRoaming no' выше частных, если они есть, директив 'Host '.
garex
15.01.2016 08:16В общесистемном обычно нету частных.
У меня там уже вверху «Host *», так что тоже необязательно, но это уже микрооптимизация конфига, которая щас меньшее зло ))
garex
15.01.2016 08:12+14Допишите в заголовок «клиенте»:
- В OpenSSH клиенте обнаружена серьёзная уязвимость CVE-2016-0777
monah_tuk
15.01.2016 08:25+2Вот отличный подход: сначала исправление проблемы, рекомендации по обходу, если обновиться сложно/невозможно, а потом публикация. А не: сначала даём на всеобщее обозрение, а потом думаем как исправлять/обходить.
monah_tuk
15.01.2016 10:01Товарищи минусующие, прошу объяснить причину вашего негодования? Как минимум я выразил уважение, что автору данной статьи, что автору (косвенно) исходного бюллетеня, что информация попала в публичный доступ после того, как были приняты меры по исправлению и поиску обходных путей решения проблемы. К примеру, в случае недавнего обсуждения проблемы в FFmpeg, получилось с точностью до наоборот.
ЗЫ хотя да, построение текста получилось сумбурным.
TimsTims
15.01.2016 10:06Уязвимость слишком серьезная, чтобы о ней молчать. Это как hearthbleed, о котором сразу раструбили
monah_tuk
15.01.2016 10:42-1Я не спорю!
Но смотри, ситуация (без привязки к конкретному софту, вообще), найдена проблема, о ней знает какое-то конечное число людей. Пусть даже среди ни есть недобросовестные, которые её эксплуатируют в своих корыстных целях. Теперь эту проблему публикуют в открытом доступе, но не дают никакой рекомендации, что делать. В результате выбор невелик: или вообще не пользоваться софтом, или любой (ну или почти, если говорить про проблему в исходном тексте) скрипт-киддер теперь может ей воспользоваться. Или другой вариант: беглое изучение в закрытом кругу, поиск вариантов быстрого закрытия проблемы, в идеале — патч и выпуск обновления, и только после этого публикация в открытом доступе. По мне, так второй вариант лучше. Действие по первому варианту, я, с натяжкой, допускаю только в случае, если разработчики не шевелятся, игнорируют.TimsTims
15.01.2016 11:23+2но не дают никакой рекомендации
Дают же
любой скрипт-киддер теперь может ей воспользоваться
Всё-же сложно такой шуткой воспользоваться без определенных навыков
патч и выпуск обновления, и только после этого публикация в открытом доступе
А теперь представьте себе компанию, которая каждый день защищается от сотен тысяч попыток проникновения, терпит и вполне успешно защищается известными практиками. Но один из хакеров покупает эту 0-day уязвимость за немалые деньги и наконец-то проникает в эту организацию, которая еще не в курсе таких выкрутасов.
Я к чему это всё говорю — при любом варианте развития будут жертвы, и очень сложно однозначно утверждать, при каком варианте жертв будет меньше.
sledopit
15.01.2016 16:16+3Теперь эту проблему публикуют в открытом доступе, но не дают никакой рекомендации, что делать. В результате выбор невелик: или вообще не пользоваться софтом, или любой (ну или почти, если говорить про проблему в исходном тексте) скрипт-киддер теперь может ей воспользоваться.
К подобным новостям пошаговых инструкций по использованию уязвимости, как правило, не прилагают. Что несколько повышает порог вхождения.
Но самое главное — предупреждён, значит вооружен. Даже если это 0-day уязвимость и никто в мире пока ещё не знает как это исправлять, лучше знать заранее и иметь возможность как минимум отключить уязвимую часть, чтобы обезопасить себя, чем потом внезапно обнаружить, что поздно пить боржоми.monah_tuk
18.01.2016 05:47Про пошаговые инструкции не говорю. Про недавний FFmpeg появилась заметка на SecurityLab с резолюцией: решения нет. Ну как нет? Можно же было пересобрать без поддержки протокола concat и/или hls. Тем временем авторы приняли и доработали фикс в части белых адресов в hls и выпустили обновления во всех поддерживаемых линейках.
monah_tuk
15.01.2016 10:46+2Да, в случае Heartbleed, можно было, по крайней мере, пересобрать без поддержки Heartbeat. Это один из вариантов WA.
DaylightIsBurning
15.01.2016 13:53+1Вы по сути пропагандируете Security through obscurity, я считаю, что это вредно. В крайнем случае, правильнее дать людям возможность отключить систему совсем (например, удалить ffmpeg на время). Уязвимость можно (по крайней мере временно) «закрыть» всегда путём отказа от части функциональности либо путем добавления «внешних» слоёв — ограничения доступа к уязвимым системам, например с помощью фаервола/антивируса и т.п.
grossws
15.01.2016 13:57У меня не возникло впечатления, что это про security through obscurity. Скорее про responsible disclosure, когда про уязвимость сообщили авторам, они успели принять меры, и только потом уязвимость была опубликована с подробным описанием.
DaylightIsBurning
15.01.2016 14:07Если авторы в сроки, сопоставимые со сроками на публикацию описания, не могу предложить решение — лучше публиковать, указывая «отключите наш сервис» в качестве решения. В противном случае это попытка полагаться на security through obscurity, когда obscurity никакой уже и нет. Пользы от совета «выключите наш сервис, он уязвим» больше, чем от попыток скрыть на время наличие уязвимости. Потому что по-нормальному защита всегда обеспечивается эшелонированием — именно для того, что бы в случае наличия проблем в одном из эшелонов можно было положиться на другие, а тем временем решать проблемы (создавать новый эшелон защиты взамен утраченному либо латать старый). Если же уязвимость скрывают, то эшелонированная защита не спасает т.к. все эшелоны могут оказаться скомпрометированными, а ответственное лицо даже не узнает об этом.
monah_tuk
18.01.2016 05:43Собственно, при любом раскладе хорошо сначала сообщить авторам — больше шансов получить более удовлетворительный ответ нежели «выключите наш сервис совсем» (например: «пересоберите без поддержки Heartbeat»), если ответа нет, то резонно действовать публично. Пересборку может выполнить и конечный потребитель, при наличии навыков, и поддерживающий пакета в дистрибутиве и выпустить как обновление безопасности.
1it
15.01.2016 09:05В macports тоже есть обновление:
$ port search openssh openssh @7.1p2 (net) OpenSSH secure login server
port install openssh
Askon
15.01.2016 10:05+1Сильно громкий заголовок, все подробности тут есть + pov: https://www.qualys.com/2016/01/14/cve-2016-0777-cve-2016-0778/openssh-cve-2016-0777-cve-2016-0778.txt
Askon
15.01.2016 10:11+2Ссылку на кволис уже давали ранее, сорри. Если б заголовок соответствовал реальному уровню опасности — была бы отличная идея для хонейпотов )
nikitasius
15.01.2016 13:59Фикс для дебиана:
проверяем версию 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) обновляем aptapt-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.
Вот и все.
ValdikSS
15.01.2016 16:06+3Ужас какой. Зачем пересобирать-то? В security-репозитории версия с патчем уже есть какое-то время.
nikitasius
15.01.2016 17:30Когда я проверял и хотел все сразу актуализировать,
apt-get install openssh-server openssh-clientвыдавал те же самые, что у меня уже стояли (на 7 и 8 дебианах).
Поэтому решил с сайта слить и пересобрать на всех.ValdikSS
15.01.2016 18:28+5У вас security-репозитории-то подключены?
А вообще, пересобирается оно сделающим образом:
apt-get source openssh-server apt-get build-dep openssh-server
Находим необходимый патч, далее:
quilt import your-patch.patch dpkg-buildpackage
Все, у нас рядом лежат собранные .deb'ы.nikitasius
15.01.2016 20:05Да, вот с виртуалки:
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
Спасибо за примеры цивилизованных апдейтов:)
mhspace
В той же цитате с HN, которую вы привели указано, что эксплуатировать уязвимость можно только с уже скомпрометированного вашего сервера.
Читайте внимательно анонс:
(хотя, при подключении к машине впервые не сверяя ключ, MITM возможен)
Вот здесь подробности.
evindor
И правда, спасибо за поправку.