Comments 29
Обнаруженный баг позволяет осуществить атаку типа 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 возможен)
Вот здесь подробности.
'Host *' не обязательна. Достаточно разместить 'UseRoaming no' выше частных, если они есть, директив 'Host '.
brew install openssh
brew install homebrew/dupes/openssh
Допишите в заголовок «клиенте»:
- В OpenSSH клиенте обнаружена серьёзная уязвимость CVE-2016-0777
Вот отличный подход: сначала исправление проблемы, рекомендации по обходу, если обновиться сложно/невозможно, а потом публикация. А не: сначала даём на всеобщее обозрение, а потом думаем как исправлять/обходить.
Товарищи минусующие, прошу объяснить причину вашего негодования? Как минимум я выразил уважение, что автору данной статьи, что автору (косвенно) исходного бюллетеня, что информация попала в публичный доступ после того, как были приняты меры по исправлению и поиску обходных путей решения проблемы. К примеру, в случае недавнего обсуждения проблемы в FFmpeg, получилось с точностью до наоборот.
ЗЫ хотя да, построение текста получилось сумбурным.
ЗЫ хотя да, построение текста получилось сумбурным.
Уязвимость слишком серьезная, чтобы о ней молчать. Это как hearthbleed, о котором сразу раструбили
Я не спорю!
Но смотри, ситуация (без привязки к конкретному софту, вообще), найдена проблема, о ней знает какое-то конечное число людей. Пусть даже среди ни есть недобросовестные, которые её эксплуатируют в своих корыстных целях. Теперь эту проблему публикуют в открытом доступе, но не дают никакой рекомендации, что делать. В результате выбор невелик: или вообще не пользоваться софтом, или любой (ну или почти, если говорить про проблему в исходном тексте) скрипт-киддер теперь может ей воспользоваться. Или другой вариант: беглое изучение в закрытом кругу, поиск вариантов быстрого закрытия проблемы, в идеале — патч и выпуск обновления, и только после этого публикация в открытом доступе. По мне, так второй вариант лучше. Действие по первому варианту, я, с натяжкой, допускаю только в случае, если разработчики не шевелятся, игнорируют.
Но смотри, ситуация (без привязки к конкретному софту, вообще), найдена проблема, о ней знает какое-то конечное число людей. Пусть даже среди ни есть недобросовестные, которые её эксплуатируют в своих корыстных целях. Теперь эту проблему публикуют в открытом доступе, но не дают никакой рекомендации, что делать. В результате выбор невелик: или вообще не пользоваться софтом, или любой (ну или почти, если говорить про проблему в исходном тексте) скрипт-киддер теперь может ей воспользоваться. Или другой вариант: беглое изучение в закрытом кругу, поиск вариантов быстрого закрытия проблемы, в идеале — патч и выпуск обновления, и только после этого публикация в открытом доступе. По мне, так второй вариант лучше. Действие по первому варианту, я, с натяжкой, допускаю только в случае, если разработчики не шевелятся, игнорируют.
но не дают никакой рекомендации
Дают же
любой скрипт-киддер теперь может ей воспользоваться
Всё-же сложно такой шуткой воспользоваться без определенных навыков
патч и выпуск обновления, и только после этого публикация в открытом доступе
А теперь представьте себе компанию, которая каждый день защищается от сотен тысяч попыток проникновения, терпит и вполне успешно защищается известными практиками. Но один из хакеров покупает эту 0-day уязвимость за немалые деньги и наконец-то проникает в эту организацию, которая еще не в курсе таких выкрутасов.
Я к чему это всё говорю — при любом варианте развития будут жертвы, и очень сложно однозначно утверждать, при каком варианте жертв будет меньше.
В первом варианте у пользователей хотя бы есть выбор.
Теперь эту проблему публикуют в открытом доступе, но не дают никакой рекомендации, что делать. В результате выбор невелик: или вообще не пользоваться софтом, или любой (ну или почти, если говорить про проблему в исходном тексте) скрипт-киддер теперь может ей воспользоваться.К подобным новостям пошаговых инструкций по использованию уязвимости, как правило, не прилагают. Что несколько повышает порог вхождения.
Но самое главное — предупреждён, значит вооружен. Даже если это 0-day уязвимость и никто в мире пока ещё не знает как это исправлять, лучше знать заранее и иметь возможность как минимум отключить уязвимую часть, чтобы обезопасить себя, чем потом внезапно обнаружить, что поздно пить боржоми.
Про пошаговые инструкции не говорю. Про недавний FFmpeg появилась заметка на SecurityLab с резолюцией: решения нет. Ну как нет? Можно же было пересобрать без поддержки протокола concat и/или hls. Тем временем авторы приняли и доработали фикс в части белых адресов в hls и выпустили обновления во всех поддерживаемых линейках.
Да, в случае Heartbleed, можно было, по крайней мере, пересобрать без поддержки Heartbeat. Это один из вариантов WA.
Вы по сути пропагандируете Security through obscurity, я считаю, что это вредно. В крайнем случае, правильнее дать людям возможность отключить систему совсем (например, удалить ffmpeg на время). Уязвимость можно (по крайней мере временно) «закрыть» всегда путём отказа от части функциональности либо путем добавления «внешних» слоёв — ограничения доступа к уязвимым системам, например с помощью фаервола/антивируса и т.п.
У меня не возникло впечатления, что это про security through obscurity. Скорее про responsible disclosure, когда про уязвимость сообщили авторам, они успели принять меры, и только потом уязвимость была опубликована с подробным описанием.
Если авторы в сроки, сопоставимые со сроками на публикацию описания, не могу предложить решение — лучше публиковать, указывая «отключите наш сервис» в качестве решения. В противном случае это попытка полагаться на security through obscurity, когда obscurity никакой уже и нет. Пользы от совета «выключите наш сервис, он уязвим» больше, чем от попыток скрыть на время наличие уязвимости. Потому что по-нормальному защита всегда обеспечивается эшелонированием — именно для того, что бы в случае наличия проблем в одном из эшелонов можно было положиться на другие, а тем временем решать проблемы (создавать новый эшелон защиты взамен утраченному либо латать старый). Если же уязвимость скрывают, то эшелонированная защита не спасает т.к. все эшелоны могут оказаться скомпрометированными, а ответственное лицо даже не узнает об этом.
Собственно, при любом раскладе хорошо сначала сообщить авторам — больше шансов получить более удовлетворительный ответ нежели «выключите наш сервис совсем» (например: «пересоберите без поддержки Heartbeat»), если ответа нет, то резонно действовать публично. Пересборку может выполнить и конечный потребитель, при наличии навыков, и поддерживающий пакета в дистрибутиве и выпустить как обновление безопасности.
В macports тоже есть обновление:
$ port search openssh
openssh @7.1p2 (net)
OpenSSH secure login server
port install openssh
Сильно громкий заголовок, все подробности тут есть + pov: https://www.qualys.com/2016/01/14/cve-2016-0777-cve-2016-0778/openssh-cve-2016-0777-cve-2016-0778.txt
Фикс для дебиана:
проверяем версию sshd
1) качаем
2) распаковываем
3) обновляем apt
4) ставим библиотеки
5) конфигурируем
6)
7)
8) если все ок, перезапускаете сервис
9) снова проверяете версию
Вот и все.
проверяем версию 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.gz2) распаковываем
3) обновляем apt
apt-get update4) ставим библиотеки
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 restart9) снова проверяете версию
telnet 127.0.0.1 12345Trying 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.
Вот и все.
А
ssh -V — выдаст версию клиента!
Ужас какой. Зачем пересобирать-то? В security-репозитории версия с патчем уже есть какое-то время.
Когда я проверял и хотел все сразу актуализировать,
Поэтому решил с сайта слить и пересобрать на всех.
apt-get install openssh-server openssh-client выдавал те же самые, что у меня уже стояли (на 7 и 8 дебианах).Поэтому решил с сайта слить и пересобрать на всех.
У вас security-репозитории-то подключены?
А вообще, пересобирается оно сделающим образом:
Находим необходимый патч, далее:
Все, у нас рядом лежат собранные .deb'ы.
А вообще, пересобирается оно сделающим образом:
apt-get source openssh-server
apt-get build-dep openssh-serverНаходим необходимый патч, далее:
quilt import your-patch.patch
dpkg-buildpackage
Все, у нас рядом лежат собранные .deb'ы.
Да, вот с виртуалки:
Спасибо за примеры цивилизованных апдейтов:)
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
Спасибо за примеры цивилизованных апдейтов:)
Sign up to leave a comment.
В клиенте OpenSSH обнаружена серьёзная уязвимость CVE-2016-0777