08.04 // Уязвимость в OpenSSL может подвергать опасности пользователей Tor и других программ
Новая уязвимость в OpenSSL 1.0 — 1.0.1 может быть использована для раскрытия данных, находящихся в памяти клиента, соединяющегося с сервером — CVE-2014-0160. Верно и обратное — раскрытие данных в памяти сервера, использующего OpenSSL, если с ним способен установить соединение злонамеренный клиент.
Использование более старых версий OpenSSL безопасно.
Проверка системной версии (не из пакета TBB):
Уязвимые на данный момент версии: 1.0.1f, 1.0.1e, 1.0.1d, 1.0.1c, 1.0.1b, 1.0.1a, 1.0.1, 1.0.2-beta1. В состав дистрибутивов Linux и др. операционных систем после исправления уязвимости могут входить версии с таким же номером, но с добавлением номера патча из пакета. Проверьте установленную версию средствами своего пакетного менеджера.
Следующие сведения имеют отношения к компонентам Tor:
- Клиенты: Непосредственно браузер из состава Tor Browser Bundle не должен быть уязвимым, т.к. использует libnss, а не openssl. Но клиенты Tor способны отправлять информацию о том, какие сайты они посещали в пределах данной сессии своим входящим узлам. Для TBB
будутнезамедлительно выпущены новые версии Tor Browser 3.5.4 is Released; для пользователей системного тор-демона необходимо будет обновить OpenSSL и вручную перезапустить Tor. - Релеи и бриджи: узлы Tor и бриджи могут производить утечку своих среднесрочных onion-ключей (меняющихся раз в неделю) или долговременных аутентификационных ключей узлов. Атакующий, который знает идентифицирующий ключ вашего релея, может опубликовать новый дескриптор сообщающий о смене вашего местоположения (не слишком опасная атака). Если при этом атакующий может перехватывать трафик до релея, знает onion-ключ, то он может перехватывать трафик от вас до вашего релея, подменяя его адрес на свой подставной. Из-за многохоповой конструкции Tor такая атака только на один узел также не слишком опасна. В любом случае, это требует обновления OpenSSL, обновления данных в DataDirectory узла и перезапуска Tor для генерации новых ключей.
- Скрытые сервисы: у них происходит утечка долговременных аутентификационных ключей к их гвард-узлам. Как и в предыдущем крупном баге в OpenSSL
это не позволит атакующему определить местоположение скрытого сервиса, но знание его ключа позволит производить его подмену. По обновлённым сведениям IP-адрес скрытого сервиса также может быть раскрыт. Рекомендуется сменить адрес скрытого сервиса после обновления.
- Корневые авторизующие диектории: у них, помимо вышеописанных утечек узловых и мостовых ключей, может происходить утечка среднесрочных ключей подписи статистики. После обновления OpenSSL их владельцам потребуется создать новые ключи подписей. Долговременные ключи находятся в оффлайне и неподвержены атаке. Из-за прописывания отпечатков ключей в код клиентов пока не выработана стратегия смены ключей с минимальным ущербом для пользователей сети.
- Tails: использует Debian oldstable и неподвержен уязвимости.
- Orbot: уязвим; детали будут опубликованы позднее.
- Большинство серверов https://www.torproject.org потребуют обновлений и смены сертификатов.
! | [WWW] Как сообщает ведущий разработчик Tor, Роджер Динглдайн, последствия Heartbleed-уязимости для сети Tor до конца не выяснены. На данный момент установлено, что она позволяет раскрывать IP-адреса скрытых сервисов. Также подозревается существование возможности проведения Heartbleed-атаки на пользователя не только со стороны сторожевых узлов, но и производя MiTM в локальной сети — например со стороны провайдера или путём перехвата беспроводного соединения. |
Источник: Torproject Blog.
Нет, конечно. Процессы то разные, и куча (heap) у каждого своя.
комментариев: 9796 документов: 488 редакций: 5664
Почему тогда в SSH блоге написано официальное предупреждение о такой возможности?
комментариев: 9796 документов: 488 редакций: 5664
Это там где пропатчено, но серты уже были стырены посредством этой дыры — да, можно делать незаметный MiTM.
А там, где непропатчено — в открытом виде можно было выуживать из дампов памяти пароли-логины. Актуально для всяких сервисов, типа веб-почты, да и простой почты тоже. Где можно завести свой аккуант и периодически логинясь, сливать пароли других пользователей, которые тоже логинятся в этот момент.
Ну или в онлайн-банке провести любые манипуляции со счётом, если там SMS-подтверждений нет. Посмотреть содержимое какой-то базы данных. FBI.gov вроде тоже был уязвим.
комментариев: 11558 документов: 1036 редакций: 4118
К сожалениюТолько веб-сервер не связан со служебной сетью.Значит они не поняли как работает уязвимость.
Они фактически утверждают, что один процесс может читать память других. Даже процесс запущенный с правами рута не сможет прочитать чужие данные используя memcpy, потому как они исполняются в параллельных виртуальных адресах. Эти "вселенные" не пересекаются.
Или у них пропущен кусок текста с объяснением как прочитав ключи из уязвимого процесса, можно получить доступ к системе и уже там добраться до SSH ключей. Всё конечно зависит от сценария. Лучше конечно перебдить, но при этом ясно понимать откуда исходит угроза.
* https://coinb.in/myaccount/account.html
@unknown, т.е. в этом кошельке coinb.in сейчас создать логин, потом специальный запрос пробьёт апач и выдаст всю его кучу в http ответе? Всех кто позалогинился недавно и ещё не дропнулся из кэша. Как это сделать? (:
login = form.getfirst('login')
password = form.getfirst('password')
hash = hashlib.sha256( password ).hexdigest()
del password
if db['login'] == hash:
комментариев: 11558 документов: 1036 редакций: 4118
Scriptkiddies в треде. Уроки все выучены? Если да, марш читать правила сайта.комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 9796 документов: 488 редакций: 5664
Эксплойты гуляли с первого дня. Ищите на соотв. ресурсах.
Хэшируется обычно на стороне сервера, значит можно отловить.
'Heartbleed' bug undoes Web encryption, reveals Yahoo passwords:
комментариев: 11558 документов: 1036 редакций: 4118
месяцыгоды — что делать с openssl в рутерах и прочих встраиваемых приложениях...комментариев: 9796 документов: 488 редакций: 5664
Производители там принципиально забивают на безопасность. А если модель уже не находится в топе продаж, то у них часто физически нет штата программеров, которые способны выпускать новые прошивки.
комментариев: 1060 документов: 16 редакций: 32
Мне механизм вот этого непонятен.
Если на современном сервере или десктопе не будет ограничений у процессов даже теоретически, то любой залетевший дятел не только прочитает всю память, но ещё и исполнит всё что захочет и станцует. Хотя на практике ни кто не застрахован от разных ошибок, в ядро тоже доктора коммитят. Но это должно быть такое же редкое исключение как и эта ошибка.
ssh.com чисто коммерческое предприятие, которое продает всякие коммерческие продукты для безопасности. Основатель компании придумал протокол (ныне SSH-1) который не считается более безопасным, а SSH-2 был доработан общими усилиями сообщества. Известно ли какой протокол ssh.com использует сейчас, если пишут:
Возможно SSH-2, но ssh.com не имеют отношения к OpenSSH.
Автор сообщения в блоге:
И вообще не понятно в какой утюг встраивают их решения, а там действительно может быть всё грустно с точки зрения безопасности процессов.